Increasingly, organizations that use large amounts of data to support their operations need tools to work with that data to support efficient operations. An example of this is data warehousing, wherein an organization compiles all of its business data such as transaction information into a centralized data warehouse that can be queried for analysis and reporting using systems such as online analysis processing (OLAP) systems, data mining, forecasting and simulation. In a typical process, an organization will assign analysts to “slice and dice” the business data in order to discover trends and potential for improvement of business processes and such analysis is followed by planning wherein business processes are devised and then put into execution.
With such systems available to the organization, many organizations find that they can use the available information in execution rather than just for improving business processes. As an example, an analyst might determine, based on the business data, that profit margins are lower for selling product to a particular geographical region and the organization might respond by implementing a business process wherein prices are increased for selected geographical regions or sales efforts in less profitable geographical regions are reduced. That is an example of business processes being developed based on analysis of the business data.
Use of the information in execution need not involve changes to the business process. For example, a shipping manager might use business data in determining where orders are being delayed and respond by finding bottlenecks in shipping and getting product out faster. In this latter use of business data, a system might monitor the business data (and possibly also the state of various other systems within the organization) and when certain events occur, issue alerts to particular participants.
Workflow Systems
Computerized workflow systems allow for collaboration that can be organized, structured and repeated, all of which supports accountability and efficiency. Of course, even with a single actor, workflow systems have benefits in the organization and structure of work. In some workflow systems, workflow is structured into instances and in a large structured workflow system, thousands of workflow instances might be processed daily.
A workflow item is a unit of a workflow system. A workflow item might represent a task that involves interaction among participants. Examples of tasks might be a team leader assigning an operation to a team member, doing the operation (performed by the team member assigned to the operation), reviewing the results of the operation (performed by a reviewer who might be the team leader, the team member or another person), signing off on the completion of the operation, tracking the task, etc.
A workflow process is a collection of tasks and links between them, where a link might provide order dependencies among tasks, rules and/or data to link tasks. For example, the tasks listed above might be part of a process wherein the team leader assigns tasks, which triggers the start of the doing of the operation, the completion of which triggers the need for review, which must occur before the signing off, while tracking can be done between the assignment and the signing off (or some other rule might apply). One workflow process might be reused many times for unrelated operations. Operations themselves might be performed using workflow processes, typically depending on complexity.
A workflow system provides each participant with an interface where actions to be done might be presented, prioritized and tracked. A workflow system might be organized in a client-server structure, with the server maintaining process templates, instances of ongoing processes, workflow items for each user and logic to present a user with his or her workflow items, via a client system. SAP's NetWeaver™ system provides an example of a workflow system.
Structured workflow has advantages of being trackable and testable. Structured workflow is trackable in that an analyst can later determine how a process proceeded and can identify other performance data and data underlying the work being done. In a typical arrangement, users have access to structured systems, such as a workflow management system and communication systems such as e-mail systems, instant messaging systems, and the like.
Event Alerts
An event resolution system might regularly issue alerts to participants based on configurable business events. The alert recipient in many cases improvises when reacting to an alert, i.e., performs actions he or she feels are appropriate. As a consequence, the quality of the event resolution depends on the intuition and experience of the alert recipient. For similar events, potentially different strategies for resolution might be taken.
As specified by the event resolution system, a participant to which an alert is to be directed can be specified as a particular individual, a particular role (e.g., the sales department manager for the Southwest Region, whoever that happens to be), a computer process that stands in as an alert recipient, or a group of one or more of the above. An alert rule base can be used to specify which events merit alerts so that participants are not swamped with alerts to the point of ignoring them, but instead receive relevant alerts such that the recipient participants can resolve or participate in the resolution of the events that generated the alerts.
An example of an alert rule is that a sales rep's supervisor is to be alerted when the delivery date for an order for that sales rep that exceeds some threshold size is delayed from its scheduled ship date by more than a threshold amount of time. It should be apparent that an event resolution system that has access to an online transaction processing (OLTP) system, an order processing system and data relating to the organization's org chart can determine delivery dates for orders, determine the sales rep for orders, determine the supervisor of the sales rep, the size of orders, the current date and an indication of how to get a message to the supervisor. Thus, an event resolution system that includes an event monitor to flag for selected events maintains a set of alert filters that specify when a participant is to be alerted about the occurrence of an event (or the lack of occurrence of an event that should have occurred).
Since alerts are filtered from events, in a well-organized system, most are nearly all of the alerts represent events that require resolution by the recipients of the alerts. In a typical response, the participant may resolve the event using the participant's knowledge and business experience and do so in an unstructured manner. For example, in the above example of an alert, the supervisor might place a call to a shipping department to check on status of the orders, place a call to the sales rep to check whether the customer has inquired about the delay, look up customer records, diagnose other possible reasons for the delay and then take some action to either resolve the delay or work with the customer to accommodate a delayed shipment. Unfortunately, when events are resolved in an unstructured manner, other participants within the organization might not be able to benefit from the first participant's knowledge and experience and the outcome of that first participant's resolution of the event.
Thus, what is needed is an approach to event resolution that takes advantage of structured workflow. Workflow processes might be generated in a business cycle that involves analysis of process data, review and planning of new business processes and then rolling out new business processes. However such an approach is often not useful given the wide range of events that business participants might have to deal with, the cost of implementing processes and the time lag between events occurring and rolling out new processes.